It is sought more particularly here below in this document to describe problems existing with the communication network of a seismic data acquisition system. The invention of course is not limited to this particular application but is of interest for any communication network that has to cope with closely related or similar issues and problems.
Typically, and as shown in FIG. 1, a seismic data acquisition system comprises a network connected to a central unit 4. In a wired implementation, the network comprises a plurality of concentrators 2,3 (i.e., according to the aforesaid generic terminology, “network nodes”, e.g. network nodes having an IP address) distributed along two types of subnets, also referred to as “lines”, usually wired lines: sensor lines 5 (also referred to as “acquisition lines”) and backbone lines 6 (also referred to as “transverse lines”).
Each concentrator 2,3 has two interfaces: a sensor line interface and a backbone line interface. When both of these interfaces are activated, the concentrator is a router concentrator 3 (i.e. a “router node”). When only the sensor line interface or the backbone interface is activated (i.e. when the concentrator is connected only to a sensor line or to only a transverse line), the concentrator 2 is non-router.
The use of sensor lines 5 and backbone lines 6 creates loops and allows seismic data to be transmitted through multiple paths. This topography with loops may avoid loosing data due to cable cuts.
The central unit 4 collects all the seismic data from seismic sensors 9 (see description below), via data acquisition units 1 (see description below) and the concentrators 2,3. The data acquisition system may be used on land or at sea (in the second case, the central unit 4 is generally on board of a ship).
A sensor line 5 (first type of subnet) comprises one or several router concentrators 3 (which are “network nodes” each connected by their sensor line interface to the sensor line) and non-router concentrators 2 (which are also “network nodes” each connected by their sensor line interface to the sensor line), assembled in series along with data acquisition units 1 (which are not “network nodes” according to above definition). In other words, a sensor line 5 is defined as a first type of subnet comprising concentrators connected together by their sensor line interface. A set of data acquisition units 1 connected to a concentrator 2,3 at least at one end is called a “segment”, which thereby is a portion of a sensor line 5. Each concentrator 2,3 (i.e. each “network node”) locally manages communication on a segment, supplies power to the data acquisition units 1 of this segment and receives seismic data generated by the data acquisition units 1 of this segment.
A backbone line 6 (second type of subnet) comprises router concentrators 3 assembled in series by their backbone line interface. Backbone lines can comprise non-router concentrators 2, but no data acquisition units 1 and have a high data-rate to rapidly transfer data. The central unit 4 is connected to at least one of the backbone lines 6.
Each data acquisition unit 1 is associated with at least one seismic sensor 9. The data acquisition units 1 process signals transmitted by the seismic sensor(s) 9 and generate seismic data. The sensors 9 are either analog sensors or digital sensors. When analog sensors (also referred to as “geophones”) are used, they are generally interconnected by cables to form clusters referred to as “strings of geophones”. One or several of these strings of geophones (in series or in parallel) are connected to each data acquisition unit 1 (which, in this case, is also referred to as FDU, for “Field Digitizing Unit”) and this latter performs an analog to digital conversion of the signal from the groups of geophones and sends these seismic data to the central unit 4 (via the concentrators 2,3). When digital sensors are used (e.g. micro-machined accelerometers, or “MEMS-based digital accelerometers”), they are usually integrated in the data acquisition units 1 (which, in this case, are also referred to as DSUs, for “Digital Sensor Units”).
In practice, the complexity of the communication network is often high. Indeed, the network comprises many subnets, with concentrators 2,3 connected to a great number of data acquisition units 1.
Moreover, the communication network may comprise a great number of subnet levels since the backbone line connected to the central unit (i.e. a first level subnet) is connected to one or several sensor lines (i.e. second level subnets), which themselves can be connected to one or several backbone lines (i.e. third level subnets), etc.—with an alternating, from one level to the other, between backbone lines and sensor lines, i.e. between first and second types of subnet for most seismic acquisition systems.
In addition, the topography of the communication network may change depending on the addition and removal of concentrators and cable cuts: existing subnets can be modified or removed, and new subnets can be added. Indeed, at any times, operators may connect and disconnect some cables of the existing network to install new concentrators, or also remove or move existing concentrators. The cables may also be partially or completely cut due to environmental stresses, thus also modifying the network topology.
In a network comprising a plurality of subnets (notably, but not exclusively, the communication network of a seismic data acquisition system), each subnet has to be configured, i.e. a distinct subnet identifier has to be associated with (i.e. allocated to) each subnet. In practice, a subnet identifier (e.g. 172.27.30.32/27) often consists of a subnet address (172.27.30.32 in aforesaid example) and a subnet mask (27 in aforesaid example).
A first known solution for configuring subnets is disclosed in the Request For Comment 6656, published by CISCO in July 2012 (ISSN: 2070-1721), with a DHCP (Dynamic Host Configuration Protocol) option that allows a DHCP client to request and obtain a subnet identifier from a DHCP server. This solution should allow a completely dynamic network configuration. But its implementation is cumbersome and complicated when the network comprises more than two (and a fortiori a great number of) subnet levels as defined above since only hierarchical transmission is foreseen.
A second known solution for configuring subnets is disclosed in U.S. Pat. No. 6,917,977, with a decentralized mechanism for an automatic allocation of subnets identifiers in a network. This solution may take a long time in case of many subnets. Moreover, it doesn't meet the challenges of frequent topology changes. If an operator makes a communication path between two subnets, address conflicts may occur. As the mechanism disclosed in this document is decentralized, this conflict will be very difficult to solve.